The present invention has broad application in a wide range of computer-driven control applications and analogous enviroments. Its virtues and operation will best be understood if it is described in the context of a specific type of control system, rather than in the abstract. For convenience, the context for explanatory purposes will be the field of industrial process control; it should be appreciated, however, that this is simply an exemplary context and is not limiting of the invention.
Industrial process control, as that term is used herein, refers to the control of manufacturing processes in industries wherein a product is, in at least some significant stage of production, a homogeneous fluid capable of being flowed in pipes or a stream of particles capable of being moved by a conveyor belt. The product can be operated upon by simple actuators such as valves, baffles and deflectors and its state can be determined (or at least estimated) by simple probing and sampling sensors. Typical industries included within this framework are those which manufacture petroleum products, chemicals, power, paper, and films, metals, textiles, plastics, foods, drugs, cement, and, increasingly, semiconductors.
Industrial processing systems, such as systems for preparing chemical compounds and for controlling other complex operation, frequently implement lengthy and highly detailed procedures. These procedures may involve hundreds, or even thousands, of steps in which various process parameters are monitored and selected process variables are controlled in predefined functional relationships which depend on the monitored parameters. Frequently, the control of such steps involves monitoring one or more measurements and initiating an action or setting a parameter (such as a temperature, pressure, composition, rate of change, amount of change, or the like) in response to the value or condition of the monitored measurement. Additionally, such procedures determine and control when individual processing steps are initiated as well as when they are terminated. Many of these steps typically must be performed in an established temporal relationship relative to one or more other steps. That is, step "x" is begun only after step "y" has been completed, or some predefined interval before or after step "y"; or steps "x" and "y" are carried out concurrently.
There are many ways in which industrial process control systems can be categorized or classified. One of the most basic categorizations groups systems into so-called "batch control" systems (or processes) and so-called "continuous control" systems. In continuous processes, production material is flowed through a series of processing units in such a way that each unit performs a logically independent production step. In batch processing, by contrast, the production material is placed in a vessel (the batch processing unit) with various pieces of support equipment. That equipment may perform multiple production steps, such as heating, cooling, and pressurizing the vessel. A batch process may carry out all production by itself or it may be arranged in a production line with other batch processes or with continuous units.
In some situations, an entire processing complex may occupy more than one square mile. With such a large facility, organization has a significant effect on efficiency. A processing complex typically may be organized into a hierarchy of (from bottom to top) units, processes and plants. At the lowest levels, the elements may be integrated in an appropriate manner governed by the requirement of meeting the detailed stoichiometric requirements involved in producing a given product. At higher levels, processing may be more flexibly arranged and rearranged to respond to the needs of the business (e.g., to take advantage of the processing units which happen to be available at the time there is a desire to manufacture a given product). The present invention, which is explained below, addresses the lower levels, where there is a desire for a highly integrated automation of control processing; it is well-suited to developing both batch control and continuous control systems. The scheduling and rearrangement of the higher level processing resources is the role of process management, not process control, and is therefore outside the scope of this invention.
In batch processing, the sequencing of the production procedure is divided hierarchically into various levels of operation. The divisions are made generally along the lines of stages of production, operator intervention and monitoring. This facilitates the use of a plant for producing a variety of products. The physical plant resources may be shared so that these products may be produced at different times while using some or all of the same production equipment, either by rearranging the processing or by using the same procedure but varying parameters to yield a different grade of product.
Control automation in this environment must provide a method for imposing control procedures in a relatively simple form.
It is also highly desireable that the control automation process automate the record-keeping associated with the production of each lot, based on the control parameterization and sources of raw materials used therefor; this is important since there is often a need or desire, at some later time, to be able to identify the source of particular characteristics in a product.
Further, a given industrial process may have to be adjusted or changed from time to time--for example, to accomodate a substitution of raw materials or to make an improvement to the product. It is therefore important that the users of a computer-controlled processing plant be able to identify the portions (and the specific instructions) of the control program which require revision. In the past, these requirements have given rise to a need for extensive documenting of such programs, parameters and materials. This level of documentation is only achieved at considerable expense. And undocumented changes could be difficult to detect and analyze.
Various computer languages have been used in the past for developing and implementing process control procedures. These languages have included general purpose computer languages such as FORTRAN, BASIC, PASCAL, C and other high-level textually-oriented programming languages, as well as specially adapted variants of such languages. Other languages used for process control applications have included graphic features such as block diagrams and ladder diagrams, either by themselves or in conjunction with textual language features; these graphic features, however, typically have no command significance. Moreover, most such prior languages share certain characteristics. For example, they typically require the user to follow a rigid control format using a general purpose instruction set. Further, they provide at best an awkward connection between control functions. These drawbacks are often the result of trying to employ a highly generalized and highly structured language which is implementation oriented instead of being intention oriented. That is, the instruction sets of those prior languages typically emphasize the implementation of an operation as a series of instructions, whereas the control system designer is concerned with what he is seeking to accomplish (i.e., his intentions). Consequently, the control system designer, though generally not interested in the details of how the machine implements each control operation, is forced to become a computer programmer. Many of the errors introduced in system control programs are believed to be the result of the constant need for mental translation which this regime imposes on the designer.
One result of this situation has been an attempt to develop programming strategies to minimize the translation effort. The most obvious of these strategies is the use of subroutines. Subroutines, however, are of only limited benefit. They help when the subroutine requires only a few arguments which act only once each time the subroutine is called. When there are many arguments which must be passed between the main program and the subroutine, though, the subroutine call becomes confusing and the order and meaning of its arguments becomes difficult to remember. Further, it can be an onerous task to link up every argument; and the format is made even more awkward when any of the arguments is optional.
Ambiguity is also a problem in most general purpose programming languages. For example, the expression I=1 could represent a direct calculation, a flag setting, a loop initialization, or some other operation. By contrast, application functions are not likely to be this general.
Another result of the conflict between the application orientation of the control designer and the implementation orientation of general purpose programming languages is that control programs written in such languages require an extensive documentation effort, if they are to be intelligible to future users and are to be capable of being modified from time to time. The documentation activity typically is two-fold. First, the source code for the program must be supported with extensive textual comments. Second, a written manual or the like must be prepared to explain the logical organization and features of the program, nomenclature of variables and labels, and other appropriate information. Consequently, each time the program is modified, the comments in the source code must be revised and the manual must be updated. With a large control program which is being used and modified by a number of people, the support effort needed to maintain up to date documentation is substantial.
It is therefore an object of the present invention to overcome some of these deficiencies by providing a new type of language structure (and translator therefor) specifically suitable for use in designing and documenting control systems.
It is a further object of the present invention to provide a computer language structure and translator which allow a control system designer to program in terms of the control functions he desires to implement, rather than in terms of the computer's internal details.
Another object of the invention is to provide a computer language structure for use in developing programs to control process operations, such that control programs developed therewith are largely self-documenting.
A still further object of the invention is to provide a computer language structure in which the temporal relationships between controlled processes is readily apparent to a reader of a program listing.
Yet another object of the invention is to provide a data structure for a programming environment in which the supporting details for carrying out control operations are segregated from expressions of control intentions, so as to enhance representation of the control intentions.
Still another object is to provide a programming environment for control system programming in which statements of control intentions can be expressed clearly and with little or no ambiguity.